home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 3720 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.4 KB

  1. Path: news.rhrz.uni-bonn.de!zeus!fasten
  2. From: fasten@zeus.informatik.uni-bonn.de (Bernhard Fastenrath)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 31 Jan 1996 19:05:49 GMT
  6. Organization: Universit"at Bonn, Informatik Abt. II, R"omerstr. 164, 53117 Bonn
  7. Message-ID: <4eoeid$k6f@news.rhrz.uni-bonn.de>
  8. References: <4e657d$2db@news.rhrz.uni-bonn.de> <4950.6603T1192T1630@teclink.net>
  9. NNTP-Posting-Host: zeus.informatik.uni-bonn.de
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. rad (rad@teclink.net) wrote:
  13.  
  14. : >Michael van Elst (mlelstv@serpens.rhein.de) wrote:
  15. : >: wayne@focus-systems.on.ca (Wayne Fisher) writes:
  16.  
  17. : ><...>
  18. : >: >    - new programs' code and data would be protected from access by
  19. : >: >    another
  20. : >: >      process unless explicitly allowed by the program.
  21.  
  22. : >: Kills close to all system functions. You had to write a completely new
  23. : >: AmigaOS.
  24.  
  25. : >Maybe not. Let's say (as you suggested earlier) that some subsystems
  26. : >(e.g. Intuition) have the permission to read and write any memory region.
  27. : >Intuition functions would have to check if the pointers received from
  28. : >process A point into A's memory and, of course, if they are consistent
  29. : >and don't corrupt Intuition's internal data when used (That's a good piece
  30. : >of work for the programmers and for Intuition at runtime but I guess it's
  31. : >possible).
  32. : >Programs which want to browse internal data structures of Intuition are
  33. : >either given permission or fail.
  34.  
  35. : First intuition is currently called within all the tasks which open it.  In
  36. : order to allow intuition to access any memory region all processes with
  37. : intuition open (practically all processes) must be able to access any memory
  38. : region, or intuition must be changed drastically to run out of a separate
  39. : process(es) in which case you add the large overhead of a context switch
  40. : for each intuition function call.  The same goes for many other libraries too.
  41.  
  42. A context switch for every intuition call is probably no a good idea (Even though
  43. it sounds like a microkernel approach).
  44. A unix system call switches to kernel mode and back to user mode by means of
  45. an interrupt without a context switch, this sounds more like what I had in mind.
  46. It should be possible to make a low-overhead switch to another mode when a
  47. system library that requires special permissions is called.
  48.  
  49. : ><...>
  50. : >: >"much more"? I don't think a few percentages is "much more".
  51.  
  52. : >: You forget that memory protection is nothing if you cannot protect
  53. : >: the system from invalid parameters to system functions. Most system
  54. : >: functions however use shared data structures.
  55.  
  56. : >How about this: Write access to a data structure shared between a process
  57. : >and Intutition marks the data structure as dirty and Intuition has to
  58. : >perform consistency checks again before using it.
  59.  
  60. : Are you willing to sacrifice the speed to do these checks on almost every
  61. : intiution function call?
  62.  
  63. Make it optional (sys:prefs/kernel).
  64.  
  65. : >: The whole concept of device drivers had to be changed.
  66. : >: BOOPSI is dead.
  67. : >: System hooks are dead.
  68.  
  69. : >Device drivers would have to be a subsystem with the license to kill
  70. : >(read/write everything). System hooks would be restricted to programs
  71. : >which were given special permission.
  72.  
  73. : The problems here are that you are punching wholes in your memory protection
  74. : for almost all software out there, and requiring major OS changes... This is
  75. : what people have been trying to point out for years.
  76.  
  77. I know :-(
  78.  
  79. : >: >It
  80. : >: >just means that you can't pass pointers between processes and the
  81. : >: >machine becomes more stable.
  82.  
  83. : >: Unfortunately most parameters are passed by pointers. You do have
  84. : >: to change everything.
  85.  
  86. : >Old programs could use one address space and pass pointers as much as
  87. : >they want to. Maybe if A calls PutMsg() it gives the receiving process B
  88. : >the permission to read/write its memory. New programs could
  89. : >also use PutMsg() but they'd allocate the message from a special pool
  90. : >and the other task receives only read/write permission for this pool.
  91. : >The private memory of new programs wouldn't have to be in the global
  92. : >address space.
  93. : >Another difference between old and new programs could be that the memory
  94. : >of old programs must not be swapped while new programs can decide for
  95. : >each of their pools if it has MEMF_SWAP set or not.
  96.  
  97. : Part of the problems with this is current software usually does not allocate
  98. : memory for messages separately from everything else leaving the OS guessing at
  99. : the size of the messages.  Further messages usually contain pointers to other
  100. : blocks of memory outside of the message which may need to be both read and
  101. : written by the receiver.  Therefor to support current programs the sender's
  102. : entire memory space must be made available to the receiver and further must be
  103. : mapped into the exact same address space for the receiver as the sender.
  104. It wouldn't have to be mapped. My idea was that old programs automatically get
  105. memory addresses which are valid in one global address space.
  106.  
  107. : Before you know it every process has access to almost every other processes
  108. : memory.
  109. That's a problem for old software, yes. A new dos.library/filesystem handler
  110. would already close the biggest hole, I guess.
  111.  
  112. : The only workable approach I see is to provide enforcer style protection for
  113. : old programs (breaks only a few poorly written/tested programs).  All tasks
  114. : can read/write all other tasks; however, access of free or non-existant memory
  115. : will kill a large percentage of "bad" programs.
  116. If there ever will be a sys:prefs/kernel they can call this
  117. "Memory Protection: Medium" :-)
  118.  
  119. : It may be possible (with great effort) to add new modes of protected memory
  120. : for new programs/libraries/devices/resources.  The problems with this are of
  121. : course major changes required of the OS, the possible requirement that new
  122. : programs only open new libraries/datatypes/devices/resources, the possible
  123. : requirement that new libraries/datatypes/devices/resources are never called by
  124. : old programs... just to name a few.
  125.  
  126. --
  127.  
  128. _|_|_|_|_|_|_|_|_|_|_|_|_|_|_///_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
  129. _| Bernhard Fastenrath      ///  http://titan.cs.bonn.edu/~fasten/ :        _|
  130. _| fasten@cs.bonn.edu   \\\///   - XWorkbench 0.2 (Amiga Workbench for X11) _|
  131. _| fasten@shw.com        \XX/    - Ext2 filesystem 0.5b for AmigaDOS, 0.3   _|
  132. _|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
  133.  
  134. Hi, I'm not a signature virus. Why don't you just copy me into your signature?
  135.